Method and System for Providing Secure Remote External Client Access to Device or Service on a Remote Network

ABSTRACT

In order to provide secure user access to a device or service on a remote network, upon receipt of a request to access the device or service on a portal on a central server, a request is sent to a probe application installed on the remote network to establish a secure link to the central server. A message is then sent to the user directing the user to initiate a specific session request to the central server. The session request is cross connected to the probe application installed on the remote network over the secure link to establish a secure tunnel to the probe application. A secure user session is set up through the secure tunnel to the device or service via the probe application.

FIELD OF THE INVENTION

This invention relates to the field of networking, and in particular toa method and system for providing secure external client access to adevice or service on a remote network.

BACKGROUND OF THE INVENTION

Users often require secure access to remote networks. For example,travelling sales personnel or teleworkers might require remote access totheir office networks. Traditionally such access has been provided usingvirtual private networks (VPNs). However, only one VPN session can berun at one time, and VPN clients do not work with other VPN servers.

Managing network systems and equipment is also getting more and morecomplicated with the growing addition of many types of systems andservices to the network. Voice services, a real-time critical system,have now migrated into this area as well, bringing all the complexitythat goes along with them. Trying to manage a network externally is amajor problem, especially from a security standpoint, as typicallynetworks can only be managed locally within the network.

SUMMARY OF THE INVENTION

The invention makes use of cloud computing technology to provide thehigh availability, scalability, and performance required for remotenetwork monitoring and management without the use of a VPN.

Accordingly the present invention a method of providing secure useraccess to a device or service on a remote network, comprising receivinga request to access the device or service on a portal on a centralserver; sending a request to a probe application installed on the remotenetwork to establish a secure link to the central server; sending amessage to the user directing the user to initiate a specific sessionrequest to the central server; cross connecting the session request tothe probe application installed on the remote network over the securelink to establish a secure tunnel to the probe application; andforwarding a user session through the secure tunnel to the device orservice via the probe application.

Embodiments of the invention make use of a server initiated port forwardand remote procedure call setup. Port forwarding typically is used toassociate a private address within a network with an address, typicallyof a router or gateway, visible to the outside world. A router receivingan incoming message addressed to its external IP address translates theport number to a private IP address and port on the internal network.

Port forwarding must be configured from within the remote network due tosecurity reasons. In accordance with an embodiment of the invention, theprobe application effectively acts as a robot setting up port forwardingwithin the remote network at the request of the external central server.

The novel solution provides a highly flexible structure and offersmultiple access levels to users. Administrator users are able toadminister end user customer accounts and to access and modify customernetwork monitoring information. An Administrator user only has access toinformation for customers created and managed by their specific VAR.Customer user accounts have limited access and can only be created by anAdministrator user to allow an end-customer to have access to theirspecific company's web portal.

There are two basic parts to the novel system:

-   -   1. A central server, which acts as a highly available and        scalable-hosted computing platform. The central server manages        communications to remote customer networks and maintains        database of status and events, and provides a Web portal with        access security. Additionally, the central server has a Remote        Access capability that provides secure “cross-connect” for        remote access to the customer network.    -   2. A probe application running on a server in the remote        customer network. The probe application has several important        functions. It initiates and maintains secure connections to the        central server, collects performance data and alarms from        devices in the Customer Networks, transfers performance data and        alarms to the central server and enables secure remote access        for the user from their location to the remote customer network.        The probe application may conveniently be provided an a        computer-readable medium, such as a CD ROM, or other storage        device, or stored on a remotely accessible server.

In another aspect the invention provides a system for providing secureuser access to a device or service on a remote network, comprising acentral server providing a portal to receive a request to access thedevice or service and configured to send a request to a probeapplication installed on the remote network to establish a secure linkto the central server; send a message to the user directing the user toinitiate a specific session to the central server; cross connect thesession request to the probe application installed on the remote networkover the secure link to establish a secure tunnel to the probeapplication; and forward a secure session through the secure tunnel tothe device or service via the probe application.

The invention also extends to a computer-readable medium containinginstructions, which when executed on a computer, implement the methodset forth above.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will now be described in more detail, by way of exampleonly, with reference to the accompanying drawings, in which:—

FIG. 1 shows the basic components of the system;

FIG. 2 shows the steps involved in setting up a remote connection;

FIG. 3 is a more detailed block diagram of one embodiment of the system;

FIG. 4 is a view similar to FIG. 3 showing the monitoring software inmore detail;

FIGS. 5-7 show the sequence of steps in setting up a connection at thecentral server;

FIG. 8 shows the monitoring software;

FIG. 9 shows the sequence of steps when a user clicks on a gadget;

FIG. 10 is a view similar to FIG. 4 showing a system employing gadgets;and

FIG. 11 shows the sequence of steps involved in setting up a connectionusing the system of FIG. 10.

DETAILED DESCRIPTION OF THE INVENTION

The basic architecture of the novel system is shown in FIG. 1. A user 10communicates with a device 20 or service on a remote network 16 over theInternet 12 via a web page provided by a web server located on a centralserver 14, referred to herein as MarCentral.

The user may wish to access a device or service on the remote network16. The system runs under a remote access application on the centralserver 14.

The invention is typically implemented as a third party service, where aservice provider or valued added reseller offers a web page allowing auser to login and access a device on a specific network.

FIG. 2 illustrates the process of establishing a connection from theuser device to the remote device 20. A probe application, hereinreferred to as Marprobe 18, is installed on the network serving theremote device.

In order to establish a connection from the user computer 10 to theremote customer device 20, the following steps are performed:

-   -   1. The user 10 connects to the web portal using HTTPS. To        initiate a remote access request the user clicks on a link for        the supported remote device in the webportal or selects a remote        IP address/port in a Gadget.    -   2. The system requests the MarProbe 18 to initiate an SSH        connection to MarCentral 14.    -   3. The system returns a URL to the user's web browser which may        direct it to initiate a specific IP protocol connection to        MarCentral 14, using a specific IP address and port.    -   4. If the connection requested is a Web connection, an        application provides a click-to-connect link in the web-portal.    -   5. For other IP protocols, the connection is made by a helper        application on the user's computer such as Putty or SSH.    -   6. The Remote Access portion of MarCentral 14 receives the        session request from the user's computer and cross-connects it        through the SSH link already established by the MarProbe 18.    -   7. The MarProbe 18 then forwards the user's IP protocol session        through the SSH Tunnel to the remote customer device.

This is a novel application of SSH Tunneling because this is done with areverse lookup. Generally, the output end of the SSH tunnel is createdwhere the request originates. This process however does not allow fortraffic to flow in the opposite direction. The simplified Remote Accesscombines the SSH tunnel creation process with our Remote Procedure Call(RPC) framework such that the request can be made within the customernetwork. The diagram below shows a simplified view of the remote accessprocess.

For certain protocols such as telnet and FTP that are not secure in theconnection between the User Computer 10 and central server 14 known asMarCentral, the Remote Access application has a local agent 118 that canbe run on the User Computer through the web. The steps to establish aconnection in this case are as follows:

-   -   1. Same as steps 1 and 2 above.    -   2. The system gives the user's web browser access to temporarily        download and run the local agent without installing it onto the        computer. The local agent already comes preconfigured with all        the connection information.    -   3. The user is told to connect to a specified port on his        computer using a specific IP protocol.    -   4. For non-web connections, the connection is made by a helper        application on the user's computer.    -   5. The local agent receives the session request from the user's        computer and cross-connects it through the SSH link already        established with MarCentral 14. The Remote Access portion of        MarCentral 14 receives the session request from the local and        cross-connects it through the SSH link already established by        the MarProbe 18.    -   6. The MarProbe 18 then forwards the user's IP protocol session        through the SSH Tunnels to the remote customer device.

The net effect of these steps is to provide the equivalent of a directconnection between the user's computer and the remote network device.The user's computer establishes a session to either MarCentral 14 orthrough the local agent to MarCentral using whatever IP Applicationprotocol is needed to connect to the remote device; the Remote Accessapplication then tunnels this session to the MarProbe 18 which forwardsto the remote device.

Since the local agent does not need to be installed onto the user'scomputer, the addition of the local agent adds a secure channel betweenthe system application and the User Computer. This forms one securetunnel between the user computer and the remote device.

It will be appreciated that although the invention has been describedusing an SSH tunnel, any protocol that provides authorization,encryption and multi-channel capability could be used instead.

Referring now to FIG. 3, which shows a detailed example of a connection,an end user 101 interfaces with the central server 111 using web Pages102 and an app 103 running on a client device connected to a LAN 104,109 or the WAN 110. Web Pages 102 can include associated applets such aslocal agent 118, which can reside in the customer site 100, the VAR(Value Added Reseller) 113, or anywhere on the Internet.

On the customer Site 100, there is a server 105, which may be in theform of a SheevaPlug 106, running the probe software 107. The probesoftware 107 interfaces with the monitoring software module 116. Manynetwork devices 108 connect to the LAN 104 are accessible to the probeSoftware 107. The LAN 104 and 109 are connected to WAN 110.

The central server 111 comprises servers 112 connected to the LAN 114,which can be running the probe software 107 for a customer, servers 115connected to the LAN 114 running the Monitoring Software 116, anddatabases 117 connected to the LAN 114.

There is an instance of the monitoring software for each VAR (Valueadded reseller) 113, and this instance manages all the different VARCustomers probe applications 107. The LAN 114 is connected to the WAN110. The VARs may provide access to customers as a service.

Referring now to FIG. 4, the Monitoring Software 116 can be furtherbroken down into a number of components. A web server 200 serves up theweb pages 102 and local agents 118 to the user and interfaces with them.A database access module 201, which accesses the Databases 117 toauthorize Users 101 trying to access the system and retrieveinformation, such as mapping information between probe applications 107and Network Devices 108. An SSH server 202 is responsible for setting upthe SSH tunnel. A Device Proxy 203 represents a device 108 on thecustomer site.

The probe Software 107 comprises an SSH client session 205, which is theend point for an SSH Tunnel, an App proxy 204, which represents anapplication 103 in the probe application Software 107, and a database206, which contains a list of Devices 108 that the probe application canaccess.

FIG. 5 is a message sequence chart showing how a Server Initiated PortForward is set up without using the local agent 118. This is a uniqueway of establishing a Port Forward operation. Step 1, at some point, anSSH tunnel over a TCP Connection is established in between the SSHServer 202 and the SSH Client Session 205. When a User 101 makes arequest for a Port Forward to a Device 108, Step 2, a Request message issent from the Web Page 102 to the Web Server 200. The Web Server 200checks the User's 101 authorization (Step 3) using Database Accessmodule 201. It then accesses the database (Step 4) through the DatabaseAccess Module 201 to retrieve the probe application that corresponds tothe Device 108 that they want to access. Step 5 and 6, the Web Server200 then asks the SSH Server 202 to create a new session to handle therequest and to Open a Port Forward to the requested Device 108.

The SSH Server 202 then forwards this request over the SSH Tunnel to theSSH Client Session 205 on the correct probe application (Step 7). Step8, the SSH Client Session checks the Probe Database 206 Device List tomake sure the Device is Accessible. The SSH Client Session 205 thensends a Request for a Port Forward to the SSH Server 202 (Step 9). Steps10 and 11, then SSH Server 202 creates a Device Proxy 203 and tells theWeb Server 200 that the Open is complete and sends it the address of theDevice Proxy 203.

In Step 12, the Web Server 200 passes the device proxy address to App103. The App 103 then establishes a connection to the far device bysending a Connect over TCP/IP to the Device Proxy 203. At this point theDevice Proxy 203 can encrypt the message, or decrypt it and re-encryptit to provide greater security. It then sends the Connect over the SSHTunnel to the SSH Client Session 205 (Step 14). Step 15, the SSH ClientSession 205 send the Connect to the Device 108. At this point a Sessionis created and Data can flow back and forth between the App 103 and theDevice 108.

FIG. 6 shows a further improvement to the process in FIG. 5, which makesthe performance of the system better. After Step 15, when the Session isestablished, the first Request made to the Device 108 can cause an AppProxy 204 to be created, and do work on behalf of the App 103. These arecustom pieces of software made for the particular App and Device. Oncethe App Proxy 204 is created, the First Request is sent to it, which ispassed on to the Device 108, but from this point on until the LastMessage is sent, then App Proxy handles all the messages to and from thedevice, cutting down on the time it takes to process them. The LastMessage is sent all the way back to the App 103 at which point the AppProxy 204 is destroyed.

FIG. 7 shows what happens if a Request for a Port Forward is made forthe same Device 108 as in FIG. 5. In this case, the Device Proxy alreadycreated is shared by the two Users 101. This means that Steps 7-10 inFIG. 5 are not necessary; the SSH Server uses the same Device Proxy 203,which has an Access Control List to keep track of the different sessionsand enforce access rules.

While FIGS. 5 to 7 illustrate processes of Remote Access using SSHTunneling, FIGS. 8 and 9 illustrate processes of Remote Access thatincludes the local Agent.

FIG. 8 is a message sequence chart showing how a Server Initiated PortForward is set up using Local Agent 118. Steps 1 to 6 are identical tothose in FIG. 5. Step 7, the SSH Server 202 generates an encryption key,authentication nonce and opens a port. SSH Server 202 then forwards thekey, nonce and socket address along with the Port Forward request overthe SSH Tunnel to the SSH Client Session 205 on the correct MarProbe.Steps 8 to 11 are the same as those in FIG. 5. It is suggest that theprevious socket address be forwarded to the device proxy address fromDevice Proxy 203. Step 12, the SSH server 202 responds to the Web Page102 with the encryption key, authentication nonce and device proxyaddress. In step 13, the Web Page 102 initializes the Local Agent 118and passes in the key, nonce and device proxy address. The Local Agent118 also opens a local port on the user computer. Step 14, Local Agent118 and SSH Client session 205 connects to the socket address providedby Device Proxy and initialize encryption by passing their key andauthentication nonce. In Step 15, the Device Proxy 203 intercepts anddecrypts initial packets from SSH Client Session 205 and Local Agent 118and matches them with the authentication nonce. Once the two parties areauthenticated, Device Proxy 203 notifies SSH Client Session 205 andLocal Agent 118 that they are now connected and authenticated. TheDevice Proxy 203 stops intercepting and decrypting data and startspassing the encrypted data between the two parties. In Step 16, the App103 establishes a connection to the far device by sending a Connect overTCP/IP to Local Agent 118. The Local Agent 118 then forwards this to theDevice Proxy 203 (Step 14). Step 17, the Device Proxy 203 sends theConnect to the SSH Client Session 205. Finally in Step 18, the SSHClient Session 205 send the Connect to the Device 108. At this point aSession is created and Data can flow back and forth between the App 103and the Device 108.

FIG. 9 shows a further improvement to the process in FIG. 8, which makesthe performance of the system better. After Step 17, when the Session isestablished, the first Request made to the Device 108 can cause an AppProxy 204 to be created, and do work on behalf of the App 103. These arecustom pieces of software made for the particular App and Device. Oncethe App Proxy 204 is created, the First Request is sent to it, which ispassed on to the Device 108, but from this point on until the LastMessage is sent, then App Proxy handles all the messages to and from thedevice, cutting down on the time it takes to process them. The LastMessage is sent all the way back to the App 103 at which point the AppProxy 204 is destroyed.

FIG. 10 contains the modules for a Remote procedure call (RPC) setup.This allows a User 101 to do RPC's on a Device from anywhere on theInternet, using the same SSH Tunnel as the Port Forwards. As shown inFIG. 10, the Web Pages 102 contain Gadgets 600, which create ProxyObjects 601. These Proxy Objects 601 represent Objects 603 created froma Set of Classes 602 associated with the SSH Client Session 205 in theprobe Software 107. This is an example of one possible method ofimplementation. The key component is the ability to create instances ofdefined functionality behind the customer's firewall.

FIG. 11 is the Message Sequence Chart of how these Proxy Objects arecreated. It is assumed that Step 1, the creation of an SSH over TCPConnection is done. On the Web Page 102, the User 101 “clicks” on aGadget 600 embedded in the page (Step 2). When this occurs (step 3, 4,5), the Gadget 600 sends an RPC Request for the particular Gadget to theWeb Server 200, which passes it to the SSH Server 202, and on to the SSHClient Session 205. In Step 6, the SSH Client Session creates theparticular Gadget X Object from Classes it has stored. Steps 7, 8 and 9,Success is passed back, and when it reaches Gadget 600, it creates aProxy Object 601 (Step 10) which has all the functions that the Classprovides, and are now available to the User through the Web Page 102.Once the RPC channels and Port Forwards are set up, the User 101 canview these sessions through the Web Page 102. Doing both of these at thesame time over the same Session is unique.

Embodiments of the invention provide a number of key advantages. Thereis no need to configure firewall rules at either the Remote Site or theReseller site. The system is configuration-free. There are no VPNclients used either at the user's PC or at the Remote Site. Differentcustomers may prefer different VPN clients and in most cases thesedifferent VPN clients cannot co-exist or operate at the same time on theuser's PC. Not using a VPN client means there is no chance of VPN clientconflict. The Remote Access service allows multiple simultaneousconnections from the user's PC to different remote sites. This is notpossible using VPN technologies. The avoidance of VPN technology meansit is not necessary to remember and secure many different User ID andPassword combinations. The Remote Access service allows administratorsto control and limit the devices you can connect to within thecustomer's network. These can also be changed on the fly and will beapplied immediately. VPN simply links you to their network.

The Remote Access Service uses standard IP security mechanisms. Thecommunication links are authenticated and encrypted. A securitycertificate is obtained from the Certificate Authority (CA) toauthenticate all connection requests. SSL sessions to the central serverare encrypted and authenticated. SSH sessions are encrypted andauthenticated as well.

The system allows either a user to establish an access control list(ACL), which applies to all remote access sessions. For instance, theACL could be set up to deny access to sensitive parts of the customernetwork and allow access only to specific devices and subnets. TheRemote Access Gadget provides information on all active remote accesssessions. All changes to the access control list take effect immediatelyfor all connections.

1-36. (canceled)
 37. A method of providing secure user access to adevice or service on a remote network, comprising: a) receiving arequest to access the device or service on a portal on a central server;b) sending a request to a probe application installed on the remotenetwork to establish a secure link to the central server; c) sending amessage to the user directing the user to initiate a specific sessionrequest to the central server; d) cross connecting the session requestto the probe application installed on the remote network over the securelink to establish a secure tunnel to the probe application; and e)forwarding a secure user session through the secure tunnel to the deviceor service via the probe application.
 38. A method as claimed in claim37, wherein at least one of: the tunnel is established using SecureShell (SSH) protocol; and the portal is in the form of a web pageaccessible by the user.
 39. A method as claimed in claim 37, wherein atleast one of: the message sent to the user includes a click-to-connectlink; and the secure user session is a specific IP protocol connection.40. A method as claimed in claim 37, wherein the secure user session isimplemented by a channel within the secure tunnel.
 41. A method asclaimed in claim 37, wherein the steps (a) to (e) are executed without astatus check from the device or service on the remote network.
 42. Amethod as claimed in claim 37, wherein the central server authenticatesusers and maintains a database mapping particular probe applications toaccessible devices on the remote network.
 43. A method as claimed inclaim 42, wherein a device proxy is created on the central server, theuser communicates with the device proxy, and the device proxycommunicates with the device or service on the remote network over thesecure tunnel to the probe application.
 44. A method as claimed in claim42, wherein a local agent is created on the local computer, the usercommunicates with the local agent, and the local agent communicates withthe central server over the secure tunnel.
 45. A method as claimed inclaim 43, wherein the user is connected to the device using portforwarding.
 46. A method as claimed in claim 43, wherein the user isconnected to the device port using port forwarding which is establishedas follows: an SSH tunnel over a TCP Connection is established inbetween an SSH server on the central server and an SSH client session onthe probe application; when the user makes a request to access thedevice a request message is sent from a user web page to the central webserver; the web server checks the user's authorization and retrieves theparticular probe application corresponding to the requested device; theweb server asks the SSH Server to create a new session to handle therequest and to open the port forward to the requested device; the SSHServer then forwards this request over the SSH tunnel to the SSH clientsession on the correct probe application; the SSH Client Session checksa database associated with the probe application to make sure the deviceis accessible; the SSH client session then sends a request for a portforward to the SSH Server; the SSH Server creates the device proxy andtells the web Server that the open port forward is complete and sendsthe open port forward and the address of the device proxy; the webserver passes the device proxy address to an application associated withthe user; the application associated with the user then establishes aconnection to the remote device by sending a connect-over-TCP/IP requestto the device proxy; and the device proxy then sends the connect requestover the SSH tunnel to the SSH client session; and the SSH clientsession sends the connect request to the device to permit data to flowback and forth between the application associated with the user and therequested device.
 47. A method as claimed in claim 43, wherein the useris connected to the device port using port forwarding which isestablished as follows: an SSH tunnel over a TCP Connection isestablished in between an SSH server on the central server and an SSHclient session on the probe application; when the user makes a requestto access the device a request message is sent from a user web page tothe central web server; the web server checks the user's authorizationand retrieves the particular probe application corresponding to therequested device; the web server asks the SSH Server to create a newsession to handle the request and to open the port forward to therequested device; the SSH Server then forwards this request over the SSHtunnel to the SSH client session on the correct probe application; theSSH Client Session checks a database associated with the probeapplication to make sure the device is accessible; the SSH clientsession then sends a request for a port forward to the SSH Server; theSSH Server creates the device proxy and tells the web Server that theopen port forward is complete and sends the open port forward and theaddress of the device proxy; the web server passes the device proxyaddress to the web browser on the user computer; the web browserinitiates the local agent with the device proxy address; the SSH clientsession connects to the device proxy address and initializes anencrypted connection; the local agent connects to the device proxyaddress and initializes an encrypted connection; the device proxyauthenticates the local agent and the SSH client session and facilitatesthe initialization of an encrypted connection between the local agentand the SSH client session; the application associated with the userthen establishes a connection to the remote device by sending aconnect-over-TCP/IP request to the local agent; the local agent thensends the connect request over the SSH tunnel, through the device proxy,to the SSH client session; and the SSH client session sends the connectrequest to the device to permit data to flow back and forth between theapplication associated with the user and the requested device.
 48. Amethod as claimed in claim 43, wherein the user is connected to thedevice port via a process employing a device proxy that encrypts anddecrypts messages passing between it and the probe application.
 49. Amethod as claimed in claim 43, wherein the user is connected to thedevice port via a process employing a web browser that downloads thelocal agent from the web server.
 50. A method as claimed in claim 43,wherein an application proxy for the application associated with theuser is created in the probe application upon receipt of a first requestto the device, and wherein intervening messages between the applicationand the device are handled by the application proxy until the lastmessage, which is sent back to the application associated with the user.51. A method as claimed in claim 43, wherein the user is connected tothe device port via a process employing a web page that contains gadgetsthat create proxy objects that represent objects created from a set ofclasses associated with a client session in the probe application topermit the user to perform a remote procedure call (RPC) setup on thedevice on the remote network.
 52. A system for providing secure useraccess to a device or service on a remote network, comprising: a centralserver providing a portal to receive a request to access the device orservice and configured to: send a request to a probe applicationinstalled on the remote network to establish a secure link to thecentral server; send a message to the user directing the user toinitiate a specific session to the central server; cross connect thesession request to the probe application installed on the remote networkover the secure link to establish a secure tunnel to the probeapplication; and forward a secure user session through the secure tunnelto the device or service via the probe application.
 53. Acomputer-readable medium containing instructions which when executed ona computer or server on a remote network establish a probe applicationfor communicating with an external central server in communication witha client user, said probe application being configured to: establish asecure link to the central server in response to a request received fromthe central server; forward a user session received from the centralserver over a secure tunnel provided by the secure link to a device orservice on the remote network, whereby a user can gain access to thedevice or service on the remote network via the central server and theprobe application.
 54. A computer-readable medium as claimed in claim53, wherein the probe application is configured to establish a PortForward upon instructions from the central server.
 55. Acomputer-readable medium as claimed in claim 53, wherein the usersession is an IP session.
 56. A computer-readable medium as claimed inclaim 53, wherein probe application is configured to at least one of:establish an SSH link to the central server, and transfer data betweenthe user system and a remote device to the central server.